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devices. Storage devices 120 typically store computer-ex- in any data structure, such as a linked list, array, set, load 
ecutable instructions to be executed by processor 110 and/or balanced tree, etc. In one embodiment, the particular entries 
data which is manipulated by processor 110 for implement- within a plurality of entries 213 are maintained in a sorted 
ing functionality in accordance with the invention. order. In one embodiment, each of the entries 213 contain a 

As used herein, computer-readable medium is an exten- 5 dirty flag (e.g., a bit) which may be used to indicate whether 
sible term including other memory and other storage devices a particular entry 213 requires synchronization or has been 
and/or mechanisms. synchronized with another database. Groups 210 may be 

Standby controller 155 includes processor and/or control divided in most any way, such as that using a hashing 
logic 160 (hereinafter "processor"), memory 165, storage function or based on a value of a location, address, connec- 

devices 170, switch interface 175, and one or more internal 10 tion identifier, etc. 

communications mechanisms 162 (shown as a bus for Initially, all the groups 210 are marked as requiring bulk 
illustrative purposes). In other embodiments, standby con- synchronization. Systematically, multiple entries 213 from 
troller 155 may include custom components such as appli- one or more groups 210 are combined into a bulk update 
cation-specific integrated circuits ("ASICs") to supplement message and relayed to a secondary device or component to 

or replace some or all of components 160-175. In one 15 bulk update the secondary database. In one embodiment, 
embodiment, processor 160 controls the operations of data structure 200 includes a dirty flag field 211 to indicate 
standby controller 155 according to the invention. Memory whether a particular group 210 is subject to a bulk update 
165 is one type of computer-readable medium, and typically technique. In one embodiment, data structure 200 includes a 
comprises random access memory (RAM), read only data field 212 which may reference or include entries 213 

memory (ROM), integrated circuits, and/or other memory 20 (e.g., connections, other data) of the actual data being 
components. Memory 165 typically stores computer-execut- synchronized within each particular group 210 of the mul- 
able instructions to be executed by processor 160 and/or data tiple groups 210. In one embodiment, each entry 213 
which is manipulated by processor 160 for implementing includes an entry dirty flag to indicate whether or not it is 
functionality in accordance with the invention. Storage subject to a bulk update. 

devices 170 are another type of computer-readable medium, 25 FIG. 3A illustrates one embodiment of a bulk update 
and typically comprise disk drives, diskettes, networked message 300. A bulk update message refers to any mecha- 
services, tape drives, and other storage devices. Storage nism which can be used to communicate multiple entries 
devices 170 typically store computer-executable instructions between two databases or data structures. Typically, bulk 
to be executed by processor 160 and/or data which is update messages are used to systematically communicate 

manipulated by processor 160 for implementing function- 30 groups of entries contained in a first database or data 
ality in accordance with the invention. structure, rather than to communicate entries in real-time as 

Switch interfaces 125 and 175 allow bulk and transac- they are received. In one embodiment, bulk update message 
tional communication between active controller 105 and bulk update message sent, for example, from an active 
standby controller 155 (and with switching elements 140) controller to a standby controller of a switching system or 

over communications link 141. This communication typi- 35 router. Message format 300 includes a header field 301, 
cally includes packets or control signals for synchronizing transaction acknowledgement request field 302 typically 
an active connection database (and/or other data structures) used to request an acknowledgement from the standby 
maintained by active controller 105 in memory 115 and/or controller, entry fields 304-306 corresponding to the data 
storage devices 120 with a secondary database (and/or other being synchronized, and a data group identifier field 303 to 

data structures) maintained by standby controller 155 in 40 indicate to which group entries 304-306 belong, 
memory 165 and/or storage devices 170. FIG. 3B illustrates one embodiment of a bulk update 

As indicated by FIGS. 1A-B, synchronization methods acknowledgement message 310 sent, for example, from a 
and apparatus according to the invention may be used in an standby controller to an active controller to acknowledge 
unbounded number of configurations and systems. FIG. IB receipt of a bulk update message 300 (FIG. 3 A) and/or 

illustrates a block diagram of another embodiment of the 45 updating of its data structure. As shown, bulk update , 

invention for synchronizing two databases using a bulk and acknowledgement message 310 includes a header field bulk 
transactional database synchronization scheme. Active ele- update), then processing proceeds to process block 410 
ment with first database 190 and standby element with where a set of entries are retrieved from one of the dirty 
second database 194 communicate bulk and transactional groups and the dirty indicators for the selected entries are 1 

messages or signals over communications network 192 and 50 reset. In one embodiment, entries within a set of entries are 
links 191 and 193. In some embodiments, active element maintained in a sorted order or using another data structure 
with first database 190 and standby element with second to make the step of getting more entries more efficient. Next, 
database 194 are located in separate components, devices or if all remaining entries to be bulk updated from the particular 
systems. In some embodiments, active element with first group have not been selected as determined in process block 

database 190 and standby element with second database 194 55 412, then the entries are put into a bulk update message and 
are implemented as part of a single computer or communi- the message being sent to the standby component in process 
cations device, with communications network 192 being, for block 414, and processing returns to process block 406 to 
example, but not limited to a data bus or some other internal process more dirty entries and groups. Otherwise, in process 
information sharing mechanism such as message passing or block 416, the transaction acknowledgement field of the 

shared memory. 60 bulk update message for the selected entries is set in process * 

FIG. 2 illustrates one data structure 200 used in one block 416, and the bulk update message is sent to the 
embodiment of a bulk and transactional database synchro- standby component in process block 418. Next, in process 
nization scheme according to the invention. In one embodi- block 420, the process waits until it receives a transaction 
ment, the primary database is divided into synchronization acknowledgement message from the standby component. In 

groups 210 of zero or more entries or transactions (hereafter 65 another embodiment, a separate process thread is used to 
"entries") 213. Entries 213 may each contain a plurality of receive the transaction acknowledgement messages. If, as 
data elements to be synchronized, which may be maintained determined in process block 422, there remains a dirty ^ 
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element in the group for which the transaction acknowl- 
edgement message was received in process block 420, 
processing returns to process block 406 to process more 
dirty entries and groups. Otherwise, the group dirty flag is 
reset for the group for which the transaction acknowledge- 
ment message was received in process block 420 and 
processing returns to process block 406 to check to see if 
there are more dirty groups to process. When there are no 
more dirty groups as determined in process block 406, then 
the bulk updating is finished as indicated by process block 
408. 

FIG. 4B illustrates one embodiment of a process of an 
active component for receiving and handling a new trans- 
action (e.g., a connection update or other primary database 
update, etc.). Processing begins at process block 430, and 
proceeds to process block 432 wherein the transaction 
request is received from another element, component, sys- 
tem, etc. The local database of the active controller is 
updated with the new transaction request in process block 
434. In one embodiment, new entries and possibly new 
groups may be created and added to the local database. Next, 
if the transaction 311, a transaction acknowledgement flag 
^feld 312 to indicate the acknowledgment, and a data group 
identifier field 313 to indicate to which group the acknowl- 
edgement refers. In one embodiment, a bulk update 
acknowledgement message 310 is used to inform the active 
controller that the standby controller has acted upon all 
entries in a group sent so far, thus eliminating ordering 
issues and providing an orderly transition of the active 
controller from a bulk update mode to a transactional update 
mode for the group or groups specified in data group 
identifier field 313, 

FIG. 3C illustrates one embodiment of a transactional 
update message 320 sent, for example, from the path man- 
ager to an active controller or from an active controller to a 
standby controller. A transactional update message refers to 
any mechanism which can be used to communicate typically 
one, but also multiple entries in real-time or almost real- 
time, and are typically used during a transactional synchro- 
nization mode. For example, shortly after updating its data- 
base with an transaction, an active controller may send to a 
standby controller the transaction using a transactional 
update message 320. In one embodiment, transactional 
update message 320 includes a header field 321 and a 
transactional update entry field 322. In one embodiment, a 
transactional update message contains either one or more 
than one transactional update entry with the entries of a 
message being from the same or different groups. 

The operation of one embodiment of a system using a 
combined bulk and transactional database synchronization 
scheme is further illustrated by the flow diagrams of FIGS. 
4A-B and 5. The operations illustrated in FIGS. 4A-B and 
5 typically operate in parallel, and may be embodied by 
numerous implementation including being performed by 
separate hardware threads or separate threads of one or more 
processes. 

FIG. 4A illustrates one embodiment of a process of an 
active component bulk updating a standby component. Pro- 
cess begins at process block 400, and proceeds to process 
block 402 where a standby initialization event is received or 
recognized to indicate that a bulk update is required. Next, 
in process block 404, all database entries and groups are 
marked as dirty to indicate that they are subject to a bulk 
I hlZJi"' N ' j. update process. Next , as determined in process blo ck 406, 
/ ril I //£ifc7\ w hile groups remain dirty (i.e., are subject to a^request 
jtl LtliTy* y^beiongs to a new bulk update group as determined in process 
block 436, then the standby database will be transactional 
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updated in process block 442 with the new transaction 
request (rather than as part of a bulk update). Otherwise, if 
the group to which the new transaction request is not dirty 
as determined in process block 438, the standby database 
will be transactional updated in process block 442 with the 
new transaction request. Otherwise, the entry previously 
added to the local database in process block 432 (and 
corresponding to the received transaction request) is marked 
as dirty in process block 440 (and the standby database will 
be bulk updated with this entry). Processing returns to 
process block 432 to receive and process more transactions. 

FIG. 5 illustrates one embodiment of a process of a 
standby component for receiving bulk and transactional 
updates from an active component and updating its database. 
Processing begins at process block 500, and proceeds to 
process block 502 wherein an update message is received 
from an active component. Next, if the message corresponds 
to a bulk update as determined in process block 504, then the 
local database of the standby component is updated with the 
entries included in the received bulk update message in 
process block 506. If an acknowledgement was requested in 
the received bulk update message as determined in process 
block 508, then a transaction acknowledgment message is 
sent to the active component in process block 510. Other- 
wise, if the message corresponds to a transactional update as 
determined in process block 504, then the local database of 
the standby component is updated with the entry or entries 
included in the received transactional update message in 
process block 512. Processing returns to process block 502 
to receive and process more update messages. 

In view of the many possible embodiments to which the 
principles of our invention may be applied, it will be 
appreciated that the embodiments and aspects thereof 
described herein with respect to the drawings/figures are 
only illustrative and should not be taken as limiting the 
scope of the invention. For example and as would be 
apparent to one skilled in the art, many of the process block 
operations can be re-ordered to be performed before, after, 
or substantially concurrent with other operations. Also, 
many different forms of data structures could be used in 
various embodiments. The invention as described herein 
contemplates all such embodiments as may come within the 
scope of the following claims and equivalents thereof. 

What is claimed is: 

1. A method for duplicating a plurality of entries of a first 
database to a second database and maintaining said entries 
in synchronization between the first database and second 
database using a combined bulk and transactional update 
scheme, wherein bulk updating refers to the initial updating 
of the second database with sets of multiple entries from the 
first database and transactional updating refers to the updat- 
ing of entries as they are applied to the first database to the 
second database for entries that are no longer subject to said 
initial bulk updating, wherein said updating of the second 
database includes committing the entry or entries to the 
second database; the method comprising: 

initializing each of a plurality of groups of said entries as 
requiring bulk updating prior to commencing updating 
of the second database with said entries, wherein, at 
least one of said groups of entries includes a plurality 
of said entries, and each of said entries are included in 
one of said groups; wherein said groups are associated 
with indications identifying which groups still require 
said bulk updating; wherein said initializing includes 
initializing said indications to identify that all of the 
groups of entries still require said bulk updating; and 
after said initializing, systematically bulk updating 
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indicate whether a particular entry 213 requires synchronization or has been 
synchronized with another database. Groups 210 may be divided in most any way, such 
as that using a hashing function or based on a value of a location, address, connection 
identifier, etc. 

5 Initially, all the groups 210 are marked as requiring bulk synchronization. 

Systematically, multiple entries 213 from one or more groups 210 are combined into a 
bulk update message and relayed to a secondary device or component to bulk update the 
secondary database. In one embodiment, data structure 200 includes a dirty flag field 
21 1 to indicate whether a particular group 210 is subject to a bulk update technique. In 
10 one embodiment, data structure 200 includes a data field 212 which may reference or 
include entries 213 (e.g., connections, other data) of the actual data being synchronized 
within each particular group 210 of the multiple groups 210. In one embodiment, each 
entry 213 includes an entry dirty flag to indicate whether or not it is subject to a bulk 
update. 

15 FIG. 3 A illustrates one embodiment of a bulk update message 300. A bulk update 

message refers to any mechanism which can be used to communicate multiple entries 
between two databases or data structures. Typically, bulk update messages are used to 
systematically communicate groups of entries contained in a first database or data 
structure, rather than to communicate entries in real-time as they are received. In one 

20 embodiment, bulk update message bulk update message sent, for example, from an active 
controller to a standby controller of a switching system or router. Message format 300 
includes a header field 301, transaction acknowledgement request field 302 typically 
used to request an acknowledgement from the standby controller, entry fields 304-306 
corresponding to the data being synchronized, and a data group identifier field 303 to 

25 indicate to which group entries 304-306 belong. 

FIG. 3B illustrates one embodiment of a bulk update acknowledgement 
message 310 sent, for example, from a standby controller to an active controller to 
acknowledge receipt of a bulk update message 300 (FIG. 3A) and/or updating of its data 
structure. As shown, bulk update acknowledgement message 310 includes a header field 

10 
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3 1 1, a transaction acknowledgement flag field 312 to indicate the acknowledgment, and a 
data group identifier field 313 to indicate to which group the acknowledgement refers. In 
one embodiment, a bulk update acknowledgement message 3 10 is used to inform the 
active controller that the standby controller has acted upon all entries in a group sent so 
far, thus eliminating ordering issues and providing an orderly transition of the active 
controller from a bulk update mode to a transactional update mode for the group or 
groups specified in data group identifier field 313. 

FIG. 3C illustrates one embodiment of a transactional update message 320 sent, 
for example, from the path manager to an active controller or from an active controller to 
a standby controller. A transactional update message refers to any mechanism which can 
be used to communicate typically one, but also multiple entries in real-time or almost 
real-time, and are typically used during a transactional synchronization mode. For 
example, shortly after updating its database with an transaction, an active controller may 
send to a standby controller the transaction using a transactional update message 320. In 
one embodiment, transactional update message 320 includes a header field 321 and a 
transactional update entry field 322, In one embodiment, a transactional update message 
contains either one or more than one transactional update entry with the entries of a 
message being from the same or different groups. 

The operation of one embodiment of a system using a combined bulk and 
transactional database synchronization scheme is further illustrated by the flow diagrams 
of FIGs. 4A-B and 5. The operations illustrated in FIGs. 4A-B and 5 typically operate in 
parallel, and may be embodied by numerous implementation including being performed 
by separate hardware threads or separate threads of one or more processes. 

FIG. 4A illustrates one embodiment of a process of an active component bulk 
updating a standby component. Process begins at process block 400, and proceeds to 
process block 402 where a standby initialization event is received or recognized to 
indicate that a bulk update is required. Next, in process block 404, all database entries 
and groups are marked as dirty to indicate that they are subject to a bulk update process. 
Next, as determined in process block 406, while groups remain dirty (i.e., are subject to a 
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bulk update), then processing proceeds to process block 410 where a set of entries are 
retrieved from one of the dirty groups and the dirty indicators for the selected entries are 
reset. In one embodiment, entries within a set of entries are maintained in a sorted order 
or using another data structure to make the step of getting more entries more efficient. 
5 Next, if all remaining entries to be bulk updated from the particular group have not been 
selected as determined in process block 412, then the entries are put into a bulk update 
message and the message being sent to the standby component in process block 414, and 
processing returns to process block 406 to process more dirty entries and groups. 
Otherwise, in process block 416, the transaction acknowledgement field of the bulk 

10 update message for the selected entries is set in process block 416, and the bulk update 
message is sent to the standby component in process block 418. Next, in process 
block 420, the process waits until it receives a transaction acknowledgement message 
from the standby component. In another embodiment, a separate process thread is used 
to receive the transaction acknowledgement messages. If, as determined in process 

15 block 422, there remains a dirty element in the group for which the transaction 

acknowledgement message was received in process block 420, processing returns to 
process block 406 to process more dirty entries and groups. Otherwise, the group dirty 
flag is reset for the group for which the transaction acknowledgement message was 
received in process block 420 and processing returns to process block 406 to check to see 

20 if there are more dirty groups to process. When there are no more dirty groups as 
determined in process block 406, then the bulk updating is finished as indicated by 
process block 408. 

FIG. 4B illustrates one embodiment of a process of an active component for 
receiving and handling a new transaction (e.g., a connection update or other primary 
25 database update, etc.). Processing begins at process block 430, and proceeds to process 
block 432 wherein the transaction request is received from another element, component, 
system, etc. The local database of the active controller is updated with the new 
transaction request in process block 434. In one embodiment, new entries and possibly 
new groups may be created and added to the local database. Next, if the transaction 
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